ПРОЦЕДУРА ИЗМЕНЕНИЯ СТОИМОСТИ И СРОКОВ ВЫПОЛНЕНИЯ РАБОТ ПО ДОГОВОРАМ СОПРОВОЖДЕНИЯ

Стоимость и срок выполнения работ связанных с разработкой или настройкой системы может быть изменен в случае изменения в процессе выполнения работ или в момент сдачи-приемки  Заказчиком ранее согласованных требований к системе. Далее описана этапы и процедура разработки функционала и условия, при которых срок и стоимость выполнения работ могут быть увеличены.

1.       Постановка задачи

Заказчик озвучивает специалистам Исполнителя требования к задаче. Специалист Исполнителя оформляет полученные требования в виде документа «Коцепция системы» и /или «Протокол прототипирования» / «Спецификация требований к системе» (далее – КС / ПрП / СТС). Специалист Заказчика знакомится с данным документом и дает свои комментарии относительно того все ли озвученные им требования учтены в документе. Если у специалиста Заказчика нет замечаний к документу, он подписывает данный документ. Затем данная задача передается в разработку.

2.       Разработка функционала

В процессе разработки может происходить выборочная или поэтапная демонстрация разрабатываемого функционала Заказчику (в случае если разрабатывается объемный функционал, который можно разделить на небольшие части, которые можно показать отдельно). Полная сдача-приемка работы может выполняться либо частями (если разрабатываемый функционал объемный и может быть сгруппирован в логические группы), либо полностью.

3.       Сдача-приемка работ

Сдача-приемка работ может происходить либо на территории Заказчика, либо удаленно путем демонстрации Заказчику разработанного функционала на тестовом примере в тестовой базе данных специалистом Исполнителя.

В случае если в процессе промежуточной демонстрации разрабатываемого функционала или уже в процессе сдачи-приемки (или в течение гарантийного срока, оговоренного в договоре сопровождения) работы специалистом Заказчика выявлены ошибки в разрабатываемом (разработанном) функционале специалист Исполнителя их записывает и передает данный функционал на доработку.

Под ошибкой понимается несоответствие функционала системы описанным в документе КС (или ПрП, или СТС; если по задаче были составлены все документы, то сравниваются требования с тем, которые описаны в документе СТС, т.к. он содержит наиболее детализированные требования; если документ СТС не составлялся, то требования сравниваются с требованиями, изложенными в документе КС).

Если в процессе промежуточной демонстрации разрабатываемого функционала или уже в процессе сдачи-приемки работы специалистом Заказчика озвучиваются новые требования к разрабатываемому (разработанному) функционалу, то специалист Исполнителя записывает их, после чего специалисты Исполнителя оценивают объем и стоимость реализации полученных новых требований и называют новый срок и стоимость выполнения работ по данной задаче. Если Заказчик согласен расширить бюджет и срок выполнения задачи с учетом новых требования, то такие требования фиксируются в документе КС (или ПрП, или СТС), специалист Заказчика их утверждает (подписывает новую редакцию документа), после чего требования передаются в разработку.

Виды документов описывающих требования к разрабатываемому функционалу:

Протокол прототипирования – документ, в котором описаны результаты сравнения потребностей Заказчика с возможностями программного продукта. Данный документ содержит такую информацию:

1)      бизнес-задача (или хоз.операция) которую нужно отразить в системе (или иметь возможность посмотреть в виде отчета),

2)      какими имеющимися в системе документами (справочниками, отчетами, обработками) может быть реализована данная задача (если в системе есть функционал позволяющий выполнить задачу),

3)      что нужно доработать в системе (если в системе недостаточно функционала для выполнения задачи пользователя); данная информация описывается в общих чертах, т.е. без детальной последовательности действий пользователя и реакции системы на каждое действие, описывается только конечный результат и несколько наиболее важных промежуточных шагов.

4)      объем трудозатрат на разработку недостающего функционала.

Концепция системы – документ, в котором на языке доступном для пользователя описано:

1)      назначение разрабатываемого функционала;

2)      последовательность действий, которые будет осуществлять в системе пользователь в работе с данным функционалом, а также реакция системы на каждое действие пользователя;

3)      функциональные требования к системе, т.е. то, что конкретно нужно разработать в системе (например, разработать новый документ с определенными реквизитами, проводками и т.п.)

Спецификация требований к системе – документ аналогичный «Концепции системы» и содержащий также техническую составляющую реализации задачи. Техническая часть документа описывается на языке понятном программистам 1С.